Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Should we adopt the KD8CEC firmware?
|
Peeps, Given that Dr.Lee's software is now pretty stable from 1.06 onwards, what do you all say about using this as the 'shipped' firmware? I have some personal quirks that make me modify it for my personal use (ex: I prefere general coverage when changing the bands rather than steps to and from ham bands) but do we consider it to be usable and stable for our needs?? I resisted feature-ful software as the base because smaller code base makes it easier for people to get in and modify, there is space in the memory for modifications, etc.? If there is a general consensus, then, we will customize it to the standard hardware, and start burning this into the next batch of ubitx. Opinions, please. - f |
|
I just noticed that the sketch is too big to get into the nano with the factory alignment enabled. this is a mandatory in the shipped firmware. I don't want to fork out and grandfather the KD8CEC versions. Not sure what to do now... - f On Sat, May 12, 2018 at 11:38 AM, Ashhar Farhan <farhanbox@...> wrote:
|
¿ªÔÆÌåÓýAshhar
You can configure the sketch so that the factory alignment is enabled and other functions are disabled.?? I am sure that Ian would configure a version that would be the current version that always had factory alignment in place. It makes a lot of sense to me to adopt the KD8CEC sketch due to the broad range of features that are added. Mike ZL1AXG On 12/05/18 6:20 PM, Ashhar Farhan wrote:
|
|
How much more space required ?
toggle quoted message
Show quoted text
At 12-05-18, you wrote: I just noticed that the sketch is too big to get into the nano with the factory alignment enabled. this is a mandatory in the shipped firmware. I don't want to fork out and grandfather the KD8CEC versions. Not sure what to do now... |
|
Stick to what you are doing.? IF anyone wants to upgrade their Raduino, they have that option with minimal effort.? I agree that the factory alignment software is vital.? TNX for all your efforts!
As of now, I have a BITX40 and two uBITX up and functioning well.? I applaud you for your efforts to bring employment to your fellow country persons (have to be politically correct here). |
|
?No disrespect to the default software of the uBitx, but from a "marketing" perspective and in my experience, Ian's software brings the rig to a more complete and enjoyable level.
So I support it to be the default software.? There is a simple and easy fix to free some extra memory for the factory alignment routines and that is to use the SoftI2CMaster I2C library instead of the Wire library. I have done that in the portable variation I uploaded to the files section and it has been working without a fault for several weeks now with both an Arduino as slave and the Si5351 on the I2C bus. This replacement library saves 1158 bytes of flash memory.? I have passed the information to Ian Lee about this. Maybe he has plans to incorporate it in a future version as he has also worked on freeing up memory for extra features. The second option is to have options in the source (like I did in the same uploaded software in the ubitx_20.ino file) with features like WSPR disabled by default and the factory alignment enabled by default. These can then be swapped with a simple addition/removal of comments ("//") in the source. This should be pretty easy to document. All the best, 73, John (VK2ETA) |
|
I don't have a real strong opinion either way but I do have one concern.? If you start shipping a CAT enabled rig you are basically giving your blessing to use digital modes on the stock radio and all the issues that come with excessive heat and the finals.? At the very least I would include a very strong warning to the user about upgrading the thermal management before going digital.? The easier you make it to do something the less likely many users are to implement proper procedures.? I am thrilled with my ?BITX and appreciate your design everyday.? I would hate to see it get a bad reputation because a bunch of unqualified new users cook the finals.
-- |
|
Jack Purdum
All:
Right now, I am not running Ian's software, but I know there are a lot of people who are. Given the alignment software that Farhan needs to be included, the switch seems to be a moot question for now unless Farhan wishes to modify the display to use fewer I/O lines. That seems like a lot of work for marginal benefit. Ian has a lot of nice features in the software and has done an amazing job getting it all packed into a very small address space. People have been successful in moving to Ian's project, so I would argue for not changing it. The documentation seems to make the switch a fairly "cookbook-like" process and painless. Also, I would like to argue for not using multiple *.ino files in any project that we use in conjunction with the ?BITX. To assess the impact, take either code project, change all the *.ino files except ubitx_20.ino to *.cpp (C++) file (ubitx_20.ino holds the setup() and loop() functions needed by the IDE and must remain a *.ino file) and then compile it. You will see numerous warnings on the compile. True, they are not errors, but warnings. By using multiple *.ino files, type checking is turned off and those warnings are hidden...their cause is still in the code, it's just that you don't know about them. Most of the time, those warnings will not cause problems, but when they do, it can be very difficult to find the bug. There may be another advantage, too. I have not checked this, but when *.cpp files are used, it appears that the IDE (Gnu) compiler can do "incremental compiles." That is, if you have not changed a given *.cpp file since the last compile, certain parts of the compile process (e.g., syntax checking) can be bypassed, resulting in slightly faster compiles. Like I said, I have not timed this yet, but I know when I start working with my project in the morning with a "fresh start", my 10,000 line project takes a fairly long time to perform that first compile. If I only change 1 file and then recompile, it is a much faster compile. I have a pretty fast PC, but I would guess that I save over 30 seconds per compile. Not a big deal unless you're doing a hundred compiles each day. In that case, it saves me almost an hour a day. To me, changing to *.cpp files and correcting the code so the warnings disappear is worth the effort. The fact that subsequent compiles may be quicker is just a dab of icing on the cake. Jack, W8TEE
On Saturday, May 12, 2018, 7:20:28 AM EDT, Raj vu2zap <rajendrakumargg@...> wrote:
How much more space required ? At 12-05-18, you wrote: I just noticed that the sketch is too big to get into the nano with the factory alignment enabled. this is a mandatory in the shipped firmware. I don't want to fork out and grandfather the KD8CEC versions. Not sure what to do now... |
¿ªÔÆÌåÓýYes, this would be a great thing to do. ? I¡¯m all for it. Now that I have 3 ubitx¡¯s I certainly can see the advantage of doing this.?On May 12, 2018, at 8:46 AM, Bo Barry <bobarr@...> wrote:
|
|
Opinions vary, no obvious winner among the options.
toggle quoted message
Show quoted text
? ??/g/BITX20/topic/7715019 Jack's recommendation is closer to what normal C programmers do, and allows the compiler to do a good job of error checking. But if there are *.c files in addition to that *.ino file, then we also have a new header file that must be kept current, which new programmers will find to be a burden. It seems ArduinoLand is structured to best support one big fat ino file. Also allows the good error checking.? Not all that big if we're coding for a Nano. Multiple *.ino files is a compromise for those that aren't comfortable with their text editor. Some error checking is defeated. Does make it easy to substitute a new keyer or CAT protocol and the like. It's a choice to be made by whoever puts it together. Those with other opinions can create their own distribution, see if it gains traction. Jerry On Sat, May 12, 2018 at 06:30 am, Jack Purdum wrote: Also, I would like to argue for not using multiple *.ino files in any project that we use in conjunction with the ?BITX. |
|
Jack Purdum
Jerry's right, a new header file is necessary so all of the now-independent files know about global variables and functions that might be shared across different files. For example, suppose you have a global variable named whichMenu and suppose ubitx_20.ino and ubitx_menu.cpp both need access to it. This is where most programmers get really sloppy: the terms "define" and "declare" are NOT the same. When you define a variable, you allocate memory space for it. When you declare a variable, you are simply creating a list of the variable's attributes that let's the compiler use it during the compile process. You can declare a variable a bazillion times in a program, but you can only define it once. So, how can I let ubitx_menu.cpp know what and where whichMenu is so the compiler can use it in that file without defining it. Simple: FILE: ? ? ? ? ? ? ? ? ? ? ?? ?? ubitx_20.ino?????????????????????????????? ubitx_menu.cpp line # 1???????????????????????? int whichMenu;????????????????????????? extern int whichMenu; The extern keyword in the menu file says to the compiler: "OK, whichMenu is not defined here (i.e., not allocated a place in memory in this file), but you can use it in this file as an int data type." So think of the compiler leaving two question marks "??" for the actually memory address that will eventually be given to whichMenu. Now, a program pass called the "linker" comes along and sees the two question marks in ubitx_menu.cpp associated with whichMenu. The linker then looks in its symbol table and says: "Oh, yeah, I assigned whichMenu to memory location 1500 back when I compiled ubitx_20.ino", so the linker replaces the two question marks with 1500. Note: Because there is no extern keyword for whichMenu in the INO file, the linker assigns it an address (i.e., defines it) when it compiles that file. This means you defined whichMenu in ubitx_20.ino, but you declared it in ubitx_menu.cpp so the compiler would let you use it in that file. Programming's hard enough without screwing up the meaning of the terms. I changed the files and created the necessary header file for Arhhar's code about two weeks after the ?BITX came out. I called it: Prototypes.h and this is what it looks like: #ifndef PROTOFLAG #define PROTOFLAG #include <Wire.h> //#include <EEPROM.h> #include <stdint.h> #include <inttypes.h> //#include <pgmspace.h> #include <Arduino.h> #include <LiquidCrystal.h> #define ENC_A (A0) #define ENC_B (A1) #define FBUTTON (A2) #define PTT?? (A3) #define ANALOG_KEYER (A6) #define ANALOG_SPARE (A7) #define TX_RX (7) #define CW_TONE (6) #define TX_LPF_A (5) #define TX_LPF_B (4) #define TX_LPF_C (3) #define CW_KEY (2) #define TX_SSB 0 #define TX_CW 1 #define MASTER_CAL 0 #define LSB_CAL 4 #define USB_CAL 8 #define SIDE_TONE 12 // these are ids of the vfos as well as their offset into the eeprom storage, don't change #define VFO_A 16// these 'magic' values #define VFO_B 20 #define CW_SIDETONE 24 #define CW_SPEED 28 void checkPTT(void);????????????????????????????????????? // from ubitx_20_standard void setFrequency(unsigned long f);?????????????????????? //????? ubitx_20_standard void startTx(byte txMode);??????????????????????????????? //????? ubitx_20_standard void stopTx();??????????????????????????????????????????? //????? ubitx_20_standard void ritDisable();??????????????????????????????????????? //????? ubitx_20_standard void ritEnable(unsigned long f);????????????????????????? //????? ubitx_20_standard void si5351bx_setfreq(uint8_t clknum, uint32_t fout);???? //????? ubitx_si5351.cpp void initOscillators(void);?????????????????????????????? //????? ubitx_si5351.cpp void si5351_set_calibration(int32_t cal);???????????????? //????? ubitx_si5351.cpp void updateDisplay(void);???????????????????????????????? //????? ubitx_ui.cpp int btnDown(void);??????????????????????????????????????? //????? ubitx_ui.cpp int enc_read(void);?????????????????????????????????????? //????? ubitx_ui.cpp void printLine1(char *c);???????????????????????????????? //????? ubitx_ui.cpp void initMeter(void);???????????????????????????????????? //????? ubitx_ui.cpp void printLine1(char *c);???????????????????????????????? //????? ubitx_ui.cpp void printLine2(char *c);???????????????????????????????? //????? ubitx_ui.cpp void doMenu(void);??????????????????????????????????????? //????? ubitx_menu.cpp void factoryCalibration(int btn);???????????????????????? //????? ubitx_menu.cpp void menuSetupCarrier(int btn);?????????????????????????? //????? ubitx_menu.cpp void factory_alignment(void);???????????????????????????? //????? ubitx_factory_alignmment.cpp void cwKeyer(void);?????????????????????????????????????? //????? ubitx_keyer.cpp void cwKeydown(void);???????????????????????????????????? //????? ubitx_keyer.cpp void cwKeyUp();?????????????????????????????????????????? //????? ubitx_keyer.cpp void checkCAT(void);????????????????????????????????????? //????? ubitx_cat.cpp #endif All of the *.cpp files #include "Prototypes.h" in them. If you look at Ashhar's code, you see why the items are in the header file. What shows me that Ashhar is a professional programmer is the absence of global variables that span multiple files (i.e., no externs). Instead, he passes the data as parameters between files, which is why we need function prototypes. If you plan on dinking around with the code, I would urge you to use *.cpp files in your project. If you just want to use the code as it is, the all-ino files is fine. Your choice. Jack, W8TEE
On Saturday, May 12, 2018, 11:13:33 AM EDT, Jerry Gaffke via Groups.Io <jgaffke@...> wrote:
Opinions vary, no obvious winner among the options. ? ??/g/BITX20/topic/7715019 Jack's recommendation is closer to what normal C programmers do, and allows the compiler to do a good job of error checking. But if there are *.c files in addition to that *.ino file, then we also have a new header file that must be kept current, which new programmers will find to be a burden. It seems ArduinoLand is structured to best support one big fat ino file. Also allows the good error checking.? Not all that big if we're coding for a Nano. Multiple *.ino files is a compromise for those that aren't comfortable with their text editor. Some error checking is defeated. Does make it easy to substitute a new keyer or CAT protocol and the like. It's a choice to be made by whoever puts it together. Those with other opinions can create their own distribution, see if it gains traction. Jerry On Sat, May 12, 2018 at 06:30 am, Jack Purdum wrote: Also, I would like to argue for not using multiple *.ino files in any project that we use in conjunction with the ?BITX. |
|
No matter what you do, Ian's software is going to fill up the nano's
memory space. That *will* limit the ability of novice and intermediate coders to make changes that they would like. In essence it will push the ubitx to being more like a kenwood/icom/yaesu rig where the software does not lend itself to experimentation by the user. Ian's software is quite easy to install if one is not interested in experimentation. Perhaps make it an ordering option? Basic software for experimenters and Ian's software for appliance operators. tim ab0wr On Sat, 12 May 2018 11:38:30 +0530 "Ashhar Farhan" <farhanbox@...> wrote: Peeps, |
|
Ashhar,
I have been using Ian's firmware because of the added features, especially CAT.? But, if possible, I would like to have the choice to use your preference?for general coverage when changing the bands rather than steps to and from ham bands.? As much as I like Ian's software as a whole, I miss that part from your firmware.? Thanks! Tom AB7WT |
|
Ian¡¯s firmware has always had the option of toggling to general coverage RX (at least since v0.33 by my notes).? How to do this is documented in the manual. M On Sun, 13 May 2018 at 7:42 AM, Tom Christian <tmchristian@...> wrote: Ashhar, |
|
Personally, I think there is great value in maintaining the original "factory" code base, simply because this is a hacker's dream! Delivering with your original core software takes nothing away from those that wish to adopt Ian's, or anyone else's mods (inclusing their own). The only drawbacks I see are: 1) Ian (or others) would have to maintain their branches if you were to make any changes to the core that would "need" to be proliferated. This can be achieved by ensuring that any changes you make to the core are communicated (documented). 2) Those enthusiasts who wish to use alternate firmware, but are not comfortable with, or equipped to, modify the Raduino may be discouraged from becoming a BitX enthusiast.? Possible solutions are building a stronger community of support (which is essentially happening with this online community), or in the extreme some of us becoming a pass-through for Raduino uogrades. Just some thoughts! Tony, KB9A? UBitx #1:? Cigar Box case, KD8CEC firmware Bitx40 #1: Grey case kit from Amateur Radio Kits, PE1NWL firmware UBitx #2: Maroon case kit from Amateur Radio Kits (still under construction) On May 12, 2018 3:42 PM, "Tom Christian" <tmchristian@...> wrote: Ashhar, |
|
Partition the code so the keyer or CAT stuff or whatever can be ifdef'd out.
toggle quoted message
Show quoted text
Then experimenters will have plenty of room to play. Jerry On Sat, May 12, 2018 at 09:14 am, Tim Gorman wrote: No matter what you do, Ian's software is going to fill up the nano's |
¿ªÔÆÌåÓýOr WSPR code¡ ? ? Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ ? Owner - Operator Big Signal Ranch ¨C K9ZC Staunton, Illinois ? Owner ¨C Operator Villa Grand Piton ¨C J68HZ Soufriere, St. Lucia W.I. Rent it: Like us on Facebook! ? Moderator ¨C North American QRO Group at Groups.IO. ? email:? bill@... ? ? From: [email protected] [mailto:[email protected]] On Behalf Of Jerry Gaffke via Groups.Io ? Partition the code so the keyer or CAT stuff or whatever can be ifdef'd out.
|
Frank PA7F
Raj vu2zap
K9HZ
to navigate to use esc to dismiss